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A Group Text Chat Purpose for Conference and Service URIs in the 
SIP Event Package for Conference State 
Abstract 
This document defines and registers a value of "grouptextchat" 
("Group Text Chat") for the URI <purpose> element of SIP’s Conference 
Event Package. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7106. 
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Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
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1. Introduction 


The Conference Event Package [RFC4575] defines means for a SIP User 
Agent (UA) to obtain information about the state of the conference, 
the types of media that are being used, the number and state of 
current participants, additional sources of information (e.g., web 
page), availability of recordings, and more. 


Details describing auxiliary services available for a conference are 
included within a <service-uris> child element of the 


<conference-description> element. Such details are presented as a 
set of <entry> child elements, each containing the URI allowing 
access the corresponding auxiliary service. In addition to the URI, 


entries can also contain a descriptive <display-text> element and are 
expected to have a <purpose> element that specifies their nature as 
illustrated in the following example: 


<conference-description> 
<subject>Agenda: This sprint’s goals</subject> 
<service-uris> 
<entry> 
<uri>http://conference.example.com/dev—group/</uri> 
<purpose>web-page</purpose> 
</entry> 
</service-uris> 
</conference-description> 


In addition to the "web-page" purpose mentioned above, [RFC4575] also 
defines several other possible values in the "URI Purposes" sub- 
registry under the existing "Session Initiation Protocol (SIP) 
Parameters" registry. 


This specification adds the "grouptextchat" value to this "URI 
Purposes" sub-registry. The new value allows conference mixers or 
focus agents to advertise a multi-user chat location (i.e., a chat 
room) associated with the current conference. 
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The actual URI carried by the entry with the "grouptextchat" purpose 
can be of any type as long as the content that it points to allows 
for instant text communication between participants of the 
conference. Suitable URI schemes include sip: and sips: [RFC3261] 
for SIP-signaled Message Session Relay Protocol (MSRP) conferences, 
xmpp: [RFC5122] for XMPP Multi-User Chat (MUC), irc: for Internet 
Relay Chat, http: or https: for web-based chat, and others. 


The following example shows one possible use case: 


<conference-description> 
<subject>Agenda: The goals for this development sprint.</subject> 
<service-uris> 
<entry> 
<uri>xmpp:dev-sprint@conference.example.com</uri> 
<purpose>grouptextchat</purpose> 
</entry> 
</service-uris> 
</conference-description> 


It is worth pointing out that, in addition to simply adding text 
messaging capabilities to an audio/video conference, group chats can 
also be used for defining roles, giving permissions, muting, kicking 
out and banning participants, etc. A conference mixer or focus agent 
can mimic these settings within the conference call, actually muting, 
kicking out, or banning participants on the call as these actions 
occur in the chat room. Such an approach requires no additional 
specification and is purely an implementation decision for the 
conferencing software. 


It is also worth mentioning that it is possible for the grouptextchat 
URI to match the URI of the conference. This would typically be the 
case in scenarios where the conference focus agent also provides a 
SIP-signaled MSRP chat service at the same URI. 


Also, in some cases, servers could potentially advertise more than a 
single chat room for a specific conference. When this happens, 
clients supporting the "grouptextchat" purpose could either present 
the user with a choice of joining individual chats or simply opening 
all of them simultaneously. Either way, there is to be no 
expectation about any content synchronization between chat rooms. If 
synchronization exists, such behavior would be entirely 
implementation specific. 
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Security Considerations 


Advertising group text chats over SIP could provide malicious 
entities with the following attack vector: if a malicious entity is 
capable of intercepting and modifying conference package event 
notifications, it could trick participants into joining a third-party 
chat room where the attacker could eavesdrop on the conversation and 
potentially even impersonate some of the participants. 


Similar attacks are already possible with the "participation" 
<conference-uris> defined in [RFC4575], which is why it recommends "a 
strong means for authentication and conference information 
protection" as well as "comprehensive authorization rules". Clients 
can integrity protect and encrypt notification messages using end-to- 
end mechanisms such as S/MIME or hop-by-hop mechanisms such as TLS. 
When none of these are possible, clients need to clearly display the 
address of the destination chat room (before and after it has been 
joined) so that users can notice possible discrepancies. 


As an example, let’s consider a situation in which an attacker tricks 
participants into joining a conference chat at 
xmpp:attack@evil.example.com rather than the chat at 
xmpp:dev-sprint@conference.example.com, which was originally 
advertised for this conference. In the absence of any SIP-layer 
security, displaying the full URI of the target chat room to the user 
would be the only way of actually detecting the problem. 


Obviously, relying on human-performed string comparison is a rather 
meek form of protection. Therefore, client developers are encouraged 
to implement additional checks that would allow users to request via 
configuration that a target chat room satisfy some basic criteria, 
such as: 


o target chat rooms belong to the same domain as the conference 
service that is advertising them. 


o chat room names (user part of the chat room URI) match the name of 
the conference. 


Once again, these conditions are only satisfied if the corresponding 
deployment conventions have been followed and they cannot be 
universally required by clients. Therefore, they are suggested 
configuration options. 


An additional security consideration might be the possibility for 
using a large-scale conference as leverage to perform a flooding 
attack on a chat room. To help prevent this, clients could to 
require an explicit user action before joining chat rooms on behalf 
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In cases where such a constraint could be considered to 


have a negative impact on usability and where automatic joins are 
seen as important, clients may still perform the joins but only when 
they can confirm a relationship between the room and the conference 
(e.g., they both belong to the same administrative domain, or domains 
that the client is provisioned to consider as related). 


Furthermore, an attack on an auxiliary chat room might be easier (or 
harder) than an attack on the main conference chat room depending on 
the security policies in effect. Once again, clients would have to 
make sure that users are appropriately notified about the security 
levels of each component of the conference and that user-specified 
privacy restrictions are applied to all of them. 


3. IANA Considerations 


IANA has 
registry 
registry 


Value: 


added the value "grouptextchat" to the "URI Purposes" sub- 
of the "Session Initiation Protocol (SIP) Parameters" 
<http://www.iana.org/assignments/sip-parameters> as follows: 


grouptextchat 


Description: The URI can be used to join a multi-user chat directly 
associated with the conference 


Document: [this document] 
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